Video zum Artikel

Podcast zum Artikel

Architektur beginnt um 9:03 Uhr

Architektur scheitert selten im großen Planungsworkshop. Sie scheitert morgens um 9:03 Uhr, wenn Slack blinkt, der nächste Termin im Kalender aufpoppt und das Tagesgeschäft die Regie übernimmt.

Noch bevor du eine Zeile Code schreibst, steckst du im Strom aus Abstimmungen und Dringlichkeiten: ein Produktionsproblem hier, eine Rückfrage dort, ein Pull Request, der auf dein Review wartet. Dabei wolltest du doch die Codebasis noch ein wenig aufräumen. Was eigentlich eine kleine Verbesserung werden sollte, wird zu einem weiteren Punkt auf deiner mentalen Vielleicht-später-Liste.

Michael Plöd schlägt einen anderen Weg vor. Im Gespräch beschreibt der INNOQ Fellow einen kleinen Bruch mit dieser Routine: zehn Minuten Verbesserung, bevor der Tag sie verschluckt.

Architektur als Praxis

Michael Plöd beschäftigt sich seit Jahren mit dem Zusammenspiel von Softwaresystemen, Teams und Organisationen. Den Software Architecture Summit eröffnet er bewusst mit einem Kontrapunkt zum KI-Hype der Stunde: Im Mittelpunkt steht nicht der nächste Technologiesprung, sondern die Frage, wie stetige Verbesserung zum festen Bestandteil professioneller Softwareentwicklung wird.

Denn die Realität sieht oft anders aus. Viele Unternehmen behandeln Modernisierung noch immer als Ausnahme: als Projekt, das Budget, Rückhalt aus dem Management und den berühmten „richtigen Zeitpunkt“ braucht. Im Alltag dominieren dagegen Features, Deadlines und Produktionsprobleme. Deshalb, so Plöd, kommt dieser richtige Zeitpunkt häufig nie.

Sein Gegenentwurf ist eine Modernisierung, die nicht auf den großen Moment wartet, sondern im Kleinen beginnt:

„Modernisierung ist kein Projekt, das wir einmal durchziehen. Sie ist eine kleine, stetige Praxis, die das Team jeden Tag in winzigen Schritten ausführt – ungefähr in dem Tempo, in dem Veränderung auf das Team einwirkt.“
— Michael Plöd

Aus diesem Gedanken entwickelt Plöd seine 1%-Methode. Die Idee stammt aus James Clears Bestseller Atomic Habits. Clear beschreibt dort, dass nachhaltiger Wandel selten durch einzelne große Entscheidungen entsteht. Wichtiger sind kleine Routinen, die sich Tag für Tag wiederholen und dadurch langfristig Verhalten verändern.

Plöd überträgt diesen Gedanken auf die Softwareentwicklung. Teams sollen nicht auf das große Refactoring warten, sondern regelmäßig winzige Verbesserungen vornehmen: einen missverständlichen Methodennamen korrigieren, eine Warnung beseitigen, einen fehlenden Test ergänzen oder einen Absatz Dokumentation aktualisieren.

Keine dieser Änderungen ist für sich genommen spektakulär. Über Monate hinweg verändern sie jedoch nicht nur die Codebasis, sondern auch die Art, wie Teams Architektur leben. Modernisierung ist dann kein mühevolles Sonderprojekt mehr. Sie wird zu einer eingeübten Praxis, so selbstverständlich wie der morgendliche Kaffee.

„Kleine Verbesserungen sind leicht zu tun. Sie sind aber auch leicht nicht zu tun. Und sie sind unmöglich zu ignorieren, sobald sie sich aufaddieren.“

— Michael Plöd

Hier beginnt der spannende Teil der 1%-Methode. Nicht bei der Frage, welche Mini-Aufgabe heute erledigt wird, sondern bei der Frage:

Was genau wird in einem Team eigentlich zur Gewohnheit?

Ein Test ist keine Gewohnheit

Auf den ersten Blick scheint die Antwort einfach zu sein. Die Gewohnheit besteht darin, jeden Tag eine Kleinigkeit zu verbessern. Schaut man genauer hin, wird die Sache komplizierter.

Denn einen Test zu schreiben, eine Variable umzubenennen oder Dokumentation zu ergänzen, sind zunächst To-Dos wie andere auch. Manche dauern zwei Minuten, andere zwanzig. Manche machen Spaß, andere schiebt man lieber vor sich her. Vor allem aber verlangen sie jedes Mal eine bewusste Entscheidung.

Genau darin unterscheiden sie sich von den klassischen Beispielen aus James Clears Atomic Habits.

Wer morgens den Laptop aufklappt, Slack öffnet oder sich den ersten Kaffee holt, denkt meist nicht lange darüber nach. Auslöser, Handlung und Belohnung greifen ineinander. Ein kurzer Blick in Slack – und das Gehirn bekommt sofort seine Rückmeldung: Was ist seit gestern passiert? Wo brennt es? Habe ich etwas verpasst? Man ist wieder im Geschehen. Diese unmittelbare Belohnung macht aus dem Klick eine klassische Gewohnheit.

Ein Refactoring funktioniert anders. Es kostet Aufmerksamkeit und konkurriert mit Features, Meetings und Produktionsproblemen. Sein Nutzen zeigt sich oft erst Wochen oder Monate später, wenn sich ein Modul leichter erweitern lässt oder ein Fehler gar nicht erst entsteht.

Deshalb verliert die kleine Verbesserung im Alltag so häufig gegen das Dringende. 

„Wenn wir Verbesserungen von Motivation abhängig machen, sehen unsere Codebasen irgendwann aus wie Fitnessstudios im März. Voll guter Vorsätze im Januar – und im Frühjahr weitgehend verlassen.“
— Michael Plöd

Plöds Antwort darauf lautet nicht: mehr Disziplin, und auch nicht: mehr Prozesse. Seine Antwort steckt in einem Begriff, den er im Gespräch eher beiläufig verwendet: Architectural Muscle Memory.

Muscle Memory beschreibt etwas anderes als Motivation. Es beschreibt eine Fähigkeit, die durch Wiederholung entsteht. Etwas, das nicht jedes Mal neu angestoßen, begründet oder erkämpft werden muss. Eine eingeübte Praxis.

Tonleitern, Boxer und Muskelgedächtnis

Wer ein Instrument lernt, kennt das Phänomen. Am Anfang kostet selbst eine einfache Tonleiter volle Konzentration. Jeder Finger wird bewusst gesetzt. Jede Bewegung wird geplant. Das Spielen beansprucht den Kopf.

Mit der Zeit verändert sich etwas – nicht das Notenblatt, nicht die Musik, sondern die Person, die sie spielt. Die Finger finden ihren Weg, ohne dass jede Bewegung bewusst geplant werden muss. Der Körper übernimmt. Musiker sprechen von Muskelgedächtnis.

Dasselbe beobachtete der französische Soziologe Loïc Wacquant im Boxring. Für seine inzwischen klassische Studie trainierte Wacquant mehrere Jahre selbst in einem Boxclub in Chicago. Dabei ging er einer grundlegenden Frage nach: Wie wird ein Mensch zum Boxer?

Gute Boxer denken im Ring nicht ständig über ihre Technik nach. Sie berechnen keine Winkel und entwerfen keine Strategie im Kopf. Sie sehen den Kampf anders. Sie spüren Distanz, Rhythmus und Gefahr, bevor sie diese benennen können. Jahrelange Übung hat ihre Wahrnehmung verändert.

Deshalb ist Plöds Begriff des Architectural Muscle Memory mehr als eine Metapher. Er meint eingeübtes professionelles Wahrnehmen und Handeln. Ein Problem fällt auf, bevor jemand es erklären muss. Etwas wirkt falsch, bevor es als Regelverstoß benannt wird.

Von der Gewohnheit zur Team-Praxis

Bis hierhin ging es um die Gewohnheiten des Einzelnen. Doch Plöd interessiert sich für mehr als individuelles Verhalten. Er spricht nicht über einzelne Entwickler, sondern über Teams. Damit rückt die gemeinsame Praxis in den Mittelpunkt.

An dieser Stelle hilft ein Blick auf den französischen Soziologen Pierre Bourdieu. Mit seinem Begriff des Habitus beschreibt er das gemeinsame, meist unausgesprochene Verständnis einer Gruppe davon, was richtig, wichtig oder selbstverständlich ist. Menschen gewinnen dieses Verständnis nicht bewusst anhand expliziter Regeln. Sie erwerben es in der täglichen Praxis und richten ihr Handeln daran aus, meist ohne es bewusst benennen zu können.

Der Habitus entscheidet nicht nur darüber, wie Menschen handeln. Er entscheidet auch darüber, was sie überhaupt wahrnehmen. Ein erfahrener Chirurg erkennt Risiken früher. Ein Fotograf sieht Licht anders. Ein Jazzmusiker hört Harmonien, die anderen entgehen. Professionelles Können besteht deshalb nicht allein aus Wissen. Es beruht auch auf geschulter Wahrnehmung.

Aus dieser Sicht bekommen die täglichen zehn Minuten eine neue Bedeutung. Sie verbessern nicht nur den Code. Sie trainieren den Blick des Teams.

Langfristig zählt nicht die einzelne umbenannte Variable, der ergänzte Test oder die bereinigte Dokumentation. Entscheidend ist, dass Teams beginnen, dieselben Dinge wahrzunehmen. Sie entwickeln ein gemeinsames Gespür dafür, wo Qualität entsteht und wo sie verloren geht.

Gute Architektur entlastet den Kopf

Der Alltag von Entwicklungsteams ist voll: Features, Produktionsprobleme, Deadlines, Meetings, Slack und ständige Wechsel zwischen Aufgaben. Oft ist von Mental Overload die Rede.

Die übliche Antwort lautet: Wir müssen stärker auf Qualität achten. Doch unter Druck hilft dieser Appell kaum. Neue Regeln belasten den Kopf nur noch mehr.

Hier liegt eine Stärke der 1%-Methode. Sie verankert gute Architektur Schritt für Schritt im Alltag, bis viele kleine Entscheidungen kaum noch bewusst getroffen werden müssen. Das ist der Sinn von Muscle Memory: Denken nicht abschaffen, sondern entlasten.

Ein eingespieltes Team muss viele Fragen nicht jedes Mal neu klären. Ein irreführender Methodenname fällt sofort auf. Eine unnötige Abhängigkeit stört. Eine fehlende Absicherung wirkt unvollständig. Nicht weil jemand gerade an die Coding Guidelines denkt, sondern weil die tägliche Praxis den Blick des Teams geschärft hat.

Der Sog guter Teams

Im Gespräch erwähnt Plöd die Idee eines Improvement-Boards. Darauf sammelt das Team kleine Aufgaben für die täglichen zehn Minuten. Das ist ein guter Einstieg: Das Board macht sichtbar, was sich verbessern lässt. Es senkt die Hürde. Niemand muss lange überlegen, wo er anfangen soll.

Doch der Team-Habitus reicht weiter. Er beantwortet die Frage: Warum ist es für uns selbstverständlich, diese Dinge verbessern zu wollen?

Hier entsteht etwas, das sich in vielen erfolgreichen Teams beobachten lässt: ein sozialer Sog.

Wer neu dazukommt, spürt diesen Sog meist schnell: beim Pair Programming, im Pull Request, in den kleinen Bemerkungen, die zunächst unscheinbar wirken:

• „Wollen wir den Namen noch etwas präzisieren?“
• „Wenn wir hier ohnehin dran sind, können wir den Test gleich ergänzen.“
• „Die Abhängigkeit fühlt sich hier falsch an.“

Das sind keine großen Architekturdebatten. Es sind kleine Korrekturen, die jeden Tag geschehen. Irgendwann wird klar: So arbeiten wir hier.

Dann vermittelt sich Architektur nicht mehr nur durch Regeln, sondern durch Praxis. Eine einzelne Gewohnheit bleibt fragil. Sie hängt von Zeit, Motivation und Disziplin ab. Ein Team-Habitus dagegen stabilisiert sich selbst. Je mehr Menschen ihn teilen, desto stärker wird sein sozialer Sog. Gute Praktiken müssen dann nicht mehr eingefordert werden. Sie werden erwartet, nicht als Vorschrift, sondern als Normalität.

Das erklärt auch, warum neue Teammitglieder häufig erstaunlich schnell den Stil eines Teams übernehmen. Menschen passen sich selten zuerst Regeln an. Sie orientieren sich daran, wie andere arbeiten. 

Software Architecture Summit: Architekturpraxis für das KI-Zeitalter

Plöds Gedanke führt zu einer einfachen, aber weitreichenden Erkenntnis: Gute Architektur entsteht nicht durch einzelne Heldinnen und Helden. Sie entwickelt sich dort, wo Teams eine gemeinsame professionelle Praxis aufbauen.

Auf dem Software Architecture Summit setzt seine Keynote dafür den Rahmen. Architektur erscheint darin als etwas, das Teams fortlaufend einüben. Die anschließenden Praxisworkshops greifen diesen Gedanken in unterschiedlichen Architekturfeldern auf.

KI-Agenten entfalten ihren Wert erst dann, wenn Teams ihren Einsatz Schritt für Schritt erproben, Ergebnisse gemeinsam prüfen und daraus verlässliche Routinen für die Modernisierung entwickeln.

→ Workshop: Agentic Software Modernization – mit KI-Agenten Softwaresysteme erneuern
Markus Harrer

Domain-driven Design wirkt nicht durch einen einzelnen Modellierungsworkshop. Es entsteht in vielen kleinen Gesprächen, in denen Teams Begriffe schärfen, Wissen teilen und ihre Modelle laufend an die Fachlichkeit anpassen. 

→ Workshop: DDD trifft LLM: Der Prompt, den du nicht tippen musst
Dr. Annegret Junker & Ferdinand Ade

Hexagonale Architektur entfaltet ihre Wirkung erst dann, wenn Teams ihre Prinzipien in den kleinen Entscheidungen des Alltags konsequent anwenden.

→ Workshop: Vom Schichten-Modell zur hexagonalen Architektur – Was, wie und warum?
Dagmar de Haan & Tom Asel

In all diesen Themen geht es um mehr als Methoden und Tools. Entscheidend ist, ob Teams die zugrunde liegenden Praktiken so einüben, dass sie auch im Alltag wirken: beim Refactoring, im Modellieren, im Umgang mit KI und in den vielen kleinen Entscheidungen, die ein Softwaresystem jeden Tag formen.

Je mehr Quellcode KI erzeugt, desto wichtiger werden menschliches Urteil und gemeinsame Qualitätsmaßstäbe. Teams müssen erkennen, ob eine Abhängigkeit an der richtigen Stelle landet, ob Geschäftslogik in die falsche Schicht rutscht oder ob ein schneller Workaround neue technische Schulden schafft. 

Damit schließt sich der Kreis zu seinem Ausgangspunkt.

Architektur entsteht selten im großen Planungsworkshop. Sie entsteht morgens. Vielleicht tatsächlich um 9:03 Uhr, in den zehn Minuten, bevor Slack den Tag übernimmt.

5 Take-aways: So wird aus einer kleinen Verbesserung Team-Praxis

1. Fang bei dir selbst an.
   Nimm dir morgen zehn Minuten für eine kleine Verbesserung. Ein besserer Name, ein fehlender Test oder eine gelöschte Warnung reichen. Wichtig ist nur, dass du anfängst.
2. Mach die Verbesserung sichtbar.
   Halte fest, was du getan hast. Eine Habit-Card, ein sauberer Diff oder ein kurzer Hinweis im Review genügt. So werden andere aufmerksam, ohne dass du die Methode erst im Meeting verkaufen musst.
3. Nimm das Team mit.
   Sammelt kleine Aufgaben auf einem gemeinsamen Improvement-Board. Dadurch kann jede Person sofort loslegen, und aus einzelnen Beobachtungen wird ein gemeinsamer Vorrat an Verbesserungen.
4. Verankert die Gewohnheit im Alltag.
   Koppelt die zehn Minuten an eine Routine, die es schon gibt: vor Slack, nach dem Stand-up oder beim Pull Request. Erst wenn die Struktur trägt, wird aus persönlichem Vorsatz ein Team-Habit.
5. Schärft gemeinsam euren Blick.
   Sprecht Qualität laut aus. Sagt im Review oder Pair Programming nicht nur, was geändert werden sollte, sondern auch warum. Aus vielen kleinen Bemerkungen entsteht mit der Zeit ein gemeinsames Verständnis dafür, was gute Architektur ausmacht.

Bonus: Mach aus der Gewohnheit kein Kontrollsystem.

Die 1%-Methode lebt von Eigenverantwortung. Sobald daraus ein Pflichtpunkt, eine KPI oder ein neues Reporting wird, ist die Gewohnheit tot. Schließlich würde auch niemand anordnen: „Ab morgen trinken alle um 9:03 Uhr zuerst einen Kaffee.“ Spätestens dann würde das halbe Team auf Tee umsteigen.